As computer networks continue to rapidly expand, there is a corresponding increase in the popularity of computer resources such as the internet and intranet. Database and server administrators must contend with issues of managing authentication of users who might have the right to access and log onto a database server. Traditionally, database server access has been managed using facilities, including user accounts and groups of proprietary and non-proprietary server operating systems (OS). These user accounts and groups are typically maintained outside the database by the server administrator. This is often a manual process, using operating system commands or specific interfaces. The process adds a great deal of overhead to the deployment and maintenance of a database system. Issues of password security and maintenance add even more overhead for the system administrator, particularly when dealing with confidential business information, and sensitive personnel records such as medical and salary histories.
The LDAP or Lightweight Directory Access protocol is an industry-standard that is used on a server operating system for maintaining operating system user accounts. Connectivity to a LDAP server is provided via the internet, the intranet or other computer network. Some computer programs for database management utilize various security mechanisms to authenticate proposed database users. These may include plug-in architectures for this purpose. As there are more automated methods for maintaining an LDAP directory than there are for maintaining operating system user accounts, these plug-ins can help to alleviate the task of maintaining large database user populations.
However, the use of an alternate mechanism, such as a proprietary LDAP plug-in, can lead to further problems for database administrators. In a proprietary database system, there are certain system accounts which may be used to install and “own” the database system. The installation and proper operation of the database requires that these accounts are integrated into the operating system and the underlying file system. However, in the implementation of certain proprietary security plug-in architectures, if an alternative plug-in is used, this plug-in completely replaces the more traditional authentication methods, for all user accounts associated with the database. This includes not only end users, but the system accounts as well. Thus, the system accounts which are required to be integrated with the operating system cannot be authenticated with the plug-in and, consequently, the database does not function.
A review of various database management systems shows a total lack of a solution that combines the ease of user maintenance provided by LDAP with the need for user accounts integrated into the underlying system. One such system has the concept of “Enterprise” users, who are identified and defined in an external directory, but must also be registered within the database itself by the database administrator, limiting the convenience of the LDAP functionality for user account maintenance. Another server system uses two modes of authentication: 1) database-based authentication, by which all user accounts are defined in the database itself; or 2) Windows® based authentication, in which user accounts are authenticated by the underlying Windows operating system, either as local logins or using an active directory. However, even with Windows-based authentication, all user accounts must be registered in the database by the database administrator as well.